Data processing systems often deal with multiple information records, each containing a number of fields of data. Certain fields may be tied to other records, and some or all of the data may be stored in a database. Because of the interrelationships between data fields, adding, changing or deleting records may be a multi-step process. For example, in an order-processing system, creation of a new order may require the order to have at least one item, but an order-item may not be valid without an order “parent.” One solution to this sort of “chicken-and-egg” problem is to create a tentative order, a tentative order item, and then to commit the two together in an atomic operation. Some databases provide a way of grouping transactions into a logical unit of work that can be all committed or all rejected. This may solve the problem of preparing a consistent set of changes, when some inconsistencies may arise during the preparation (to be resolved before committing the unit of work), but leads to another, related problem.
While processing a unit of work, derivative data may be generated by the system based on data in the database, entries from a user, or by other operations of an application. In some circumstances, this derivative data may be useful even though the original data from the user or the database is not useful. For example, if the user tries, but fails, to create a consistent set of records, the system may provide error messages to explain why the records are invalid. The user may wish to save the messages—even in the database—but the system may not provide a way to save only part of a unit of work. Committing the work may be an all-or-nothing proposition, and it may be undesirable or impossible to store the inconsistent records just to ensure that the derivative data is also saved. Methods of operating a data processing system to preserve data related to a unit of work, without also saving the work itself, may be of value.